【レポート】「第12回Ques」に参加してきました #ques12

2018年11月16日(金)に開催された 「第12回Ques」 に参加してきましたので、まとめレポートを書こうと思います。
今回は「AI時代の品質」をテーマに、AIについて「テストの視点」からの報告がメインとなりました。
まだ一部の資料を取得できていないので、取得でき次第添付します。

ATNDのイベントページ

目次

• 1.「Ques」について
• 2.挨拶
• 3.自動テスト × 機械学習 ～自動テスト結果分析は楽になるか？
• 4.AIのテスト ～画像認識における誤検知と検出漏れ
• 5.懇親会
• 6.まとめ

1.「Ques」について

私も今回始めて知ったイベントなのですが、こちらに「Quesとは？」というズバリなページがあったので、それを引用します。

Quesとは、Software品質保証に関わるQAエンジニアの活性化を目的としたQA専門のイベントです。 Software品質保証に関わるQAエンジニアの方が、会社間の垣根を越えて、情報交換や交流を深めてもらう事で、日本のSoftware品質保証を盛り上げていく場にしたいと思います。

ちなみに、呼び方は「キューズ」です。 今後も年に2回（5,11月）実施していく予定とのことです。

ちなみに、今回はノベルティとしてハイチュウもいただけました。

今回のノベルティはハイチュウです #ques12 pic.twitter.com/UNEr3KqJA4

— Quesの中の人 (@Ques_staff) 2018年11月16日

2.挨拶

まずは、「Ques事務局」の「宮本　由布樹」さんから簡単にご挨拶があり、「Ques」の今までの経緯や、Quesブログについてのご紹介がありました。
(画質が悪いです...)

Quesブログは「QA(Quality Assurance)」に関する記事が多く、品質保証に興味のある方は一度見てみるといいかもしれません。

3.自動テスト × 機械学習 ～自動テスト結果分析は楽になるか？

続いて、「株式会社ヒューマンクレスト」の「山口 真央」さんの報告です。
「自動テストに機械学習を組み込んだ事例」という私が聞いたことがない領域の話だったので、とても面白かったです。

Quesブログのご講演者インタビューもアップされていますので、よろしかったらこちらもご覧ください。

もしよかったらスライドもご参照ください。

●テーマの経緯

自動テストでは、「結果の分析が大変」、「自動テストを作っている人がいなくなると、そのシステムが使えなくなる」といった問題を抱えており、 「より自動テストの結果分析を簡単にできないか？」という目的のもと、下記の2パターンを試したとのことです。

• レイアウト崩れ自動検知
• 自動テスト結果分析

●レイアウト崩れ自動検知の経緯

この検知は、「従来手動でやっていた作業をより簡単にできないか」、「会社で提供している自動化サービスに対して、お客様からレイアウトチェックもできないかと相談されていた」といった背景から取り組んだそうです。

従来から社内でも「OpenCV」を使ってレイアウト崩れチェックのテストはしていたものの、このやり方ではまだまだ課題（ex.サイトのデザイン変更,広告の投入等があったらエラーになる）が残っていたため、「画像１枚だけでテストできたらいいのに」という考えがスタートラインになったそうです。
より具体的には、レイアウトが崩れている箇所について、「位置」、「どのくらい崩れているか」を取得すること、をゴールとして設定したそうです。

●技術要素と実施事項(レイアウト崩れ自動検知経緯)

実際に利用した技術要素についても説明してくださいました。
まずは、「レイアウト崩れした画像を集める」ところから始め、下記の５点を試してみたそうです。

当日の報告では、この5点のうち下記の2点をピックアップしてお話しくださいました。

要素・位置からレイアウト崩れを検出

• OpenCVで要素を抽出。
• 抜き出した要素が「何か」を機械学習で分類。

要素の分類はできそうだが、データが不足していたため結果が安定せず、「レイアウトが崩れると領域の抽出がうまくいかない」ということがわかった段階でこの手法は一旦保留としたそうです。

１枚の画像からレイアウト崩れ検出

• １枚の画像とレイアウトを比較して「OK/NG」を返すことを目的として実施。
• 推論をする前に、「スクリーンショットをリサイズ」していたのだが(モデル生成時に利用した画像のサイズと合わせる必要があるため)、その時点で「レイアウト崩れ」かどうかが人間でわかるレベルなので、実質意味がない、という気づきを得たそうです。

●課題

ここまでの振り返りとして、下記の事柄が課題として判明したそうです。
また、「機械学習でできることの整理」ができていないと辛いところがある、とのことでした。

• 「レイアウト崩れしている画像」の収集が難しい(「puppeteer」を使って無理やり収集したが、無理がありそう)
• 「レイアウト崩れ」の判定に時間がかかる

●自動テスト結果の分析

続いて、「自動テスト結果の分析」に対して機械学習を活用した事例の紹介に移りました。

背景としては、エラー発生時の「一次切り分け」（ex.原因が「環境」、「タイムアウトエラー」、「不具合」のいずれなのか）が大変なので自動化したい、といったものだそうです。
「レイアウト崩れ自動検知」の時とは異なり、今回はデータを集める仕組みができていたので、それをうまく使えないか、と考えたそうです。
(Lynxというサービスを提供しており、ここにデータを貯めていた、とのことです)

●INPUT,OUTPUT等のデータ周りについて

自動テストの「シナリオ」、「設定」をINPUT、「エラー情報等」をOUTPUTと定義しました。

また、利用するデータについては、３年半分のデータがあったものの、全期間のデータを機械学習でやるのは難しく、また傾向も変わっているため、使うデータを絞ったとのことです。

また、全体のデータの傾向を確認した結果、「エラーの報告結果が色々なところに分散して存在している。（slack,gmail,レッドマイン,lynx等）」、「必要な情報が不足していた」ことがわかり、「データ設計の頃からしっかりやっておいた方がよかった」といった振り返りが得られた、とのことです。

●説明変数について

下記のような説明変数を利用したそうです。

●データ分析結果

全体を一気に見ても要点が把握しづらいので、データを絞って分析したそうです。

「AWS、社内ローカル環境のどちらで実行した方がいいのか」、というのが前から気になっていた、という背景から、AWSとローカルでの「テスト結果比較」をしてみたところ、特に差異はないことが分かったそうです。

続いて、「ブラウザごとの比較」をしてみたところ、「成功率はそこまで変わらない」、「IE11は実行時間が長い」といったことが分かったそうです。

●各ステップ毎の実行時間予測

普段から「タイムアウトエラーが多い」、というのを感じていたことから「ステップごとの実行時間予測」を試したそうです。
もし実行時間が予測できれば、適切な待ち時間を指定することでエラーが減り、その結果テスト結果分析の数が減る、という流れを想定していらっしゃいました。

今回はPythonの一般的な機械学習ライブラリである「sklearn」で5つのモデルを試したそうです。
各モデルの結果を比較したところ、「RandomForest Regressor」が一番良い結果がでたものの、「まだ誤差が大きい」とのことでした。

●今後の課題

「データが一番大事」ということを実感し、まずは「データ収集の仕組み」を作るところを、いずれは「画面崩れ検知」に再挑戦したい、とのことでした。

また、「色々やったけどまだ難しくて、半年くらいやってまだ少しだけなんとなくわかってきた、というくらい」という感想もおっしゃっていました。
機械学習については「実際にやってみてわかることも多い」と私も感じているので、この感想にはただただ共感するばかりです。

●Q&A

最後にQ&Aがあったので、いくつか質問をピックアップしておきます。

Q:テスト設計自動化に役立てたい、ということはすでに何らかのビジョンがあるかと思うのですが、さわりだけでも教えていただけないでしょうか？
A:自動テスト結果を役立てたい、とは考えているが細かいところはこれから考えていきたい

Q:「待機時間の予測」について、「タイムアウトエラー」対策としてはElementを使えば良いのでは？
A:今後はElementを使う予定です

Q:「レイアウト崩れ」について、「崩れている箇所」を検出して、「そこがどれだけ崩れているか」を予測すれば良いのでは、と思うのですがいかがでしょうか
A:それについてはある程度取り組もうとしていたので、もう少ししっかり取り組んでいけたら、と思っています。

4.AIのテスト ～画像認識における誤検知と検出漏れ

続いて、「株式会社クロノス」の「大石 宏一」さんの報告です。　　
「AIを内包したプロダクトにおける品質とは」について改めて考えさせられる内容でした。

Quesブログのご講演者インタビューもアップされていますので、よかったらこちらもご覧ください。

また大石様の登壇資料については、こちらをご参照ください。

●会社紹介

まずは「株式会社クロノス」さんの紹介からです。
「株式会社クロノス」さんはAIやアプリの開発に携わっており、「AI×Data活用研究会」を主催しているそうです。

●品質のあるべき姿

品質基準がないところが多く、ウォーターフォール形式で要件定義等に落とし込んでいるうちに「客の課題解決」から離れていくことが問題であり、現代におけるプロダクトでは、「欠陥がないだけではなく、品質特性を実現できていることが必要」である。
また、日経BPが調査した結果で、今までは「品質」と言っていた項目が「満足度」という名前に変更されていることからも、「考え方を変化するターニングポイントに来ており、顧客の課題に正面から向き合える時代がきた」と大石さんは考えておられるそうです。

また、AIは「やってみないとわからない」という特徴から、ウォーターフォール系ではなくアジャイル的な取り組み方でないと合わない、とのことでした。

●事例概要

実際に「清掃会社でAIを内包したアプリ」の活用事例を紹介してくださりました。
この業界は差別化が難しく、「AIを使って差別化したい」、というインセンティブから始まったそうです。
そこで、清掃員がスマホで動画を撮って、AIがゴミを検出し、地図上に「どこに何がどのくらいあった」というのをヒートマップで表示するアプリを開発したそうです。

●品質担保の方針

機械学習のコードはそこまで長くないので、「そもそもバグが入りづらい」ものです。そこで、「AIの品質」を「目的に沿った精度がどれだけ出せるか」ということで評価することとしたそうです。

例えば、物体検出アルゴリズムでは「誤検知と検出漏れはトレードオフ」¹になることが多いため、一言で「精度」と言っても難しいものなのですが、今回の清掃会社の場合は「取りこぼしを減らしたい」とのことなので「多少の誤検知があろうが、検出漏れを減らす」方針にしたそうです。

●モデルの生成過程

続いて、実際にどのように開発作業を進めたのか、という報告に移りました。
まずは社員総出で３週間かけてデータを収集し、拡張したデータセット等を含めて様々なモデルを生成してみたそうです。
モデル生成のアルゴリズムには「Tensorflow Object Detection API」を活用したそうです。

データは「zipファイル」で貯めてからバッチ処理とし、最終的な精度は80％程度まで出たそうです。 また、ここで精度向上を追求するのではなく、「UIで解決する」方針を目指し、顧客と検出の閾値について交渉し、リリースに至ったそうです。
この舵きりも「品質」を「顧客の満足度」として考えた結果、とのことです。

●Q&A

最後にQ&Aがあったので、いくつか質問をピックアップしておきます。

Q:清掃会社がヒートマップを使って解決したかった課題は？
A:会社に依頼を出す行政側が「費用対効果」を把握しやすくする。いつもどこにゴミが溜まっているのか、というのがわかるので「ゴミ捨て禁止の看板」や「タバコの灰皿立てをここに設置したらいい」とか、ゴミ削減の対策方針の検討に役立つ。

Q:具体的にはどのような話の流れになったのか
A:お客様から課題を伺った後に、AI推進担当者が考えたものを提案しました。基本的にお客様のニーズに合わせてカスタマイズすることが多いです

Q:地方と都内でゴミの内容が異なると思うが、それで誤検知とかはなかったのか
A:ありました(ex.コンクリート上のゴミ、公園とかに落ちているゴミ)。今回の検証では全て「東京」で集めたデータでやりました。

Q:品質基準が設けられていない、とあるが今回の事例での「品質基準」は何か
A:お客様の「満足度」です。感想をもらって、測る形になります。

5.懇親会

セッション終了後は懇親会に移りました。

お酒やおつまみを提供していただき、色々な方とお話しすることができました。

6.まとめ

機械学習の勉強会にはちょこちょこ参加しているのですが、「品質」をメインとしたイベントは凄く貴重であり、とても参考になりました。
機械学習のシステムを運用している方々の参考になれば幸いです。